What is the best way to contact docbook and let them know about this bug?

Can you provide a sample document that you believe should validate but doesn't? This document validates for me:

<article xmlns="http://docbook.org/ns/docbook">
<title>Test</title>

<informaltable>
<tbody>
<tr>
  <th>Heading</th>
</tr>
<tr>
  <td><para>This is a paragraph.</para>
  </td>
</tr>
</tbody>
</informaltable>

</article>

@ndw can you try to test any block (not inline) element inside the table cell? F.e.

<article xmlns="http://docbook.org/ns/docbook">
<title>Test</title>

<informaltable>
<tbody>
<tr>
  <th>Heading</th>
</tr>
<tr>
  <td>
   <blockquote />
  </td>
</tr>
</tbody>
</informaltable>

</article>

a011b56 is faling without this PR.

The problem with that example isn't in the table, it's in the blockquote. DocBook does not allow an empty block quotation. This validates just fine for me:

<article xmlns="http://docbook.org/ns/docbook">
<title>Test</title>

<informaltable>
<tbody>
<tr>
  <th>Heading</th>
</tr>
<tr>
  <td><blockquote><para/></blockquote>
  </td>
</tr>
</tbody>
</informaltable>

</article>

@ndw you are correct. After spending more time on this issue, seems like the true reason was found: there was zero width space (U+200B) after the child element in the table cell. Child element was a block type. So our case was:

<article xmlns="http://docbook.org/ns/docbook">
  <title>Test</title>
  <informaltable>
    <tbody>
      <tr>
        <th>Heading</th>
      </tr>
      <tr>
        <td>
          <blockquote>
            <para/>
          </blockquote>
          [zero width space]
        </td>
      </tr>
    </tbody>
  </informaltable>
</article>

The current PR makes this content valid, and no validation erros are thrown. But, I assume, the more correct solution would be to fix the code which adds zero width space (instead of changing the rng schema).

@ndw can you think about any other cases where zero width space might lead to validation errors?

@vidarl seems like this one might be closed in the flavor of ezsystems/ezplatform-admin-ui@9e8739d

It took me a few minutes to get my head around this. The XML Recommendation defines whitespace as explicitly (and exclusively) SPACE ( ), TAB ( ), and NEWLINE ( )[]. Any other character that occurs between block elements (including zero-width space, non-breaking space, etc. etc. etc.) is effectively text where it isn't allowed. A zero-width space where only elements are allowed is going to cause validation errors every time. [] Technically, CARRIAGE RETURN (#xD;) is also part of the space production, but the parser removes them or converts them to NEWLINE in all cases except where they occur as explicit numeric character references.
…
On Tue, Aug 13, 2019 at 6:25 AM Serhey Dolgushev @.> wrote: @vidarl https://github.com/vidarl seems like this one might be closed in the flavor of @. <ezsystems/ezplatform-admin-ui@9e8739d> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#56?email_source=notifications&email_token=AAAI7OKSJQVVKBZRPGFBJD3QEKKY5A5CNFSM4IKAGMB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4FLOFI#issuecomment-520795925>, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAI7OMSLFTKIYW5VAB2GMTQEKKY5ANCNFSM4IKAGMBQ .

Yep, this one was fun :)
It was very difficult to discover that empty width space between the child elements of td. And as you said it counts like a text, which explains why validation error was triggered. So no changes in the schema are required. It needs to be fixed in the app logic which is responsible for generating XML.

@ndw Thank you a lot for your input!